SEP 2 -- 系统健康监控方案

全站访问性能

第三方监控云服务：腾讯云的拨测，听云，OneAPM,监控宝等（待决策）

问题：
1. 静态资源访问性能
2. 接口访问性能

拨测

介绍：对网站、域名、后台接口等进行周期性监控，可通过查看可用率和延时随时间区间变化来帮助分析站点质量情况。

费用：免费，但限制了最多可配置10个拨测任务（一个任务对应一个接口）。

监控数据：各区域可用率和接口延时趋势，配置可用率的阈值能达到邮件报警的作用。

优点：免费，而且就在腾讯云上面
缺点：监控数量被限制，无法分析静态页面的性能

听云

介绍：基于真实用户的浏览器端网站性能监测，可配置关键页面和关键ajax的监控，可设置告警阈值通过邮件发送。


优点：需要解决的问题都可以解决，支持告警
缺点：费用高，需要在html页面配置听云JS探针（传数据到它们服务器的脚本）

监控宝

优点：需要解决的问题都可以解决，可以加探针，也可以不加探针
缺点：费用高，100api配额的监控，一年是20w，网页性能监控0.3元/次

oneAPM

Bi功能：受访页面、Ajax、脚本错误、浏览器、地理、运营商。
这部分数据对前端工程师非常重要，白屏时间、首屏时间、网页就绪时间，OneAPM 统计了每一个 URL 的这些指数的平均时间，从中找出最耗时间的 URL ，对代码响应的改良。


优点：需要解决的问题都可以解决
缺点：费用待咨询，需要在html页面配置听云JS探针（传数据到它们服务器的脚本），不支持告警，报表是下载的

性能报告

每日发昨日数据的统计报告。

接口性能报告：多维度统计

平均时长排序，前10条。
最长时间排序，前10条。
请求个数排序，前10条。

新增mangodb表
表名：requests_log
字段：
id
request_url         str         请求接口
request_method      str         请求方式
processing_time     decimal     处理时间（秒）
request_params      str         请求参数
request_time        datetime    请求时的时间
line_number         int         行号
request_uid         int         在base类里面创建的一个用于标记每个请求的uid,方便后续查询
http_status         int         http状态
exception           str         报错信息
service_name        str         提供服务的平台
create_time         datetime    创建时间


新增mangodb表
表名：requests_log_summary
字段：
id
details    array_object   每种类型的详细信息

           request_url         str         请求接口
           request_method      str         请求方式
               decimal     处理时间（秒）
           request_params      str         请求参数
           request_time        datetime    请求时的时间
           line_number         int         行号
           request_uid         int         在base类里面创建的一个用于标记每个请求的uid,方便后续查询
           http_status         int         http状态
           avg_time            double      平均时长，log_type为1时会有
           request_count       int         请求个数，log_type为3时会有
           exception           str         报错信息，log_type为5时会有

log_type            str         记录类型，1：平均时长，2：最长时间，3：请求个数，4：非200错误，5：exception错误
service_name        str         提供服务的平台
create_time         datetime    创建时间


解决方案：重写common 里面的base类，计算每个接口处理时间,按特殊格式打印到日志的方式，顺便把所有模块都做一个access日志，定时脚本去分析数据。

非200错误或者exception，在重写的base里面发送邮件，并打印到日志。

新开一个监控工程。

统计脚本所要做的任务：
1.  每天1点统计分析各个平台的log日志
2.  分析日志，把超过3s的请求保存到requests_log里面
2.  记录接口的性能，从表日志里面 取前10的平均时长，最长时间，请求个数  保存到requests_log_summary
3.  统计非200，和exception的日志到requests_log和requests_log_summary
4.  处理下面慢查询日志，输出到报告
5.  把以上信息输出到报表，发送到邮件组

DB性能报告：慢查询报告

解决方案：

* mongo开启慢查询，设置慢查询阈值1s，日志是放在system.profile里面的，通过定时脚本查询前一天的慢查询放到报告里面（保存为文件）。
* mysql开启慢查询，设置慢查询阈值1s，慢查询日志可以存储在日志文件里面，用脚本执行 mysql-log-filter 分析日志放入报告中（保存为文件）(mysql看了下后台管理里面基本没有慢日志，所以暂时没做)

系统报错监控

http非2XX错误（直接在上面重写的base类抓取到，下面的Nginx拉去暂定）

拉取ngnix日志，所有的http非2xx返回都可能是异常，需要逐个分析。

解决方案：定时脚本，通过ngxtop 这个包 查出前一天不为2XX的数据，列出对应状态对应的含义及日志记录的信息，放入报告中。

业务代码exception

业务代码的所有exception都需要分析。

解决方案：重写的base类可以抓取到所有exception，可以发送邮件通知，并打印到日志，用于每日脚本抓取，放入报告中。

业务代码非0返回（非0 的日志信息已经打印到access里面了）

业务代码的非0返回，有些是正常的业务流程，有些确实是系统出错，这里可能需要提前做好一些配置能力，能够根据接口和错误码过滤掉一些合理的报错。

暂定：把非0 的日志信息已经打印到access里面了